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Abstract 


The Secure Shell (SSH) is a protocol for secure remote login and 
other secure network services over an insecure network. 


This document describes the SSH transport layer protocol, which 
typically runs on top of TCP/IP. The protocol can be used as a basis 
for a number of secure network services. It provides strong 
encryption, server authentication, and integrity protection. It may 
also provide compression. 


Key exchange method, public key algorithm, symmetric encryption 
algorithm, message authentication algorithm, and hash algorithm are 
all negotiated. 


This document also describes the Diffie-Hellman key exchange method 
and the minimal set of algorithms that are needed to implement the 
SSH transport layer protocol. 
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1. Introduction 


The SSH transport layer is a secure, low level transport protocol. 
It provides strong encryption, cryptographic host authentication, and 
integrity protection. 


Authentication in this protocol level is host-based; this protocol 
does not perform user authentication. A higher level protocol for 
user authentication can be designed on top of this protocol. 


The protocol has been designed to be simple and flexible to allow 
parameter negotiation, and to minimize the number of round-trips. 
The key exchange method, public key algorithm, symmetric encryption 
algorithm, message authentication algorithm, and hash algorithm are 
all negotiated. It is expected that in most environments, only 2 
round-trips will be needed for full key exchange, server 
authentication, service request, and acceptance notification of 
Service request. The worst case is 3 round-trips. 


2. Contributors 


The major original contributors of this set of documents have been: 
Tatu Ylonen, Tero Kivinen, Timo J. Rinne, Sami Lehtinen (all of SSH 
Communications Security Corp), and Markku-Juhani O. Saarinen 
(University of Jyvaskyla). Darren Moffat was the original editor of 
this set of documents and also made very substantial contributions. 


Many people contributed to the development of this document over the 
years. People who should be acknowledged include Mats Andersson, Ben 
Harris, Bill Sommerfeld, Brent McClure, Niels Moller, Damien Miller, 
Derek Fawcus, Frank Cusack, Heikki Nousiainen, Jakob Schlyter, Jeff 
Van Dyke, Jeffrey Altman, Jeffrey Hutzelman, Jon Bright, Joseph 
Galbraith, Ken Hornstein, Markus Friedl, Martin Forssen, Nicolas 
Williams, Niels Provos, Perry Metzger, Peter Gutmann, Simon 
Josefsson, Simon Tatham, Wei Dai, Denis Bider, der Mouse, and 
Tadayoshi Kohno. Listing their names here does not mean that they 
endorse this document, but that they have contributed to it. 


3. Conventions Used in This Document 


All documents related to the SSH protocols shall use the keywords 
"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" to describe 
requirements. These keywords are to be interpreted as described in 
[RFC21189]. 
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The keywords "PRIVATE USE", "HIERARCHICAL ALLOCATION", "FIRST COME 
FIRST SERVED", "EXPERT REVIEW", "SPECIFICATION REQUIRED", "IESG 
APPROVAL", "IETF CONSENSUS", and "STANDARDS ACTION" that appear in 
this document when used to describe namespace allocation are to be 
interpreted as described in [RFC2434]. 


Protocol fields and possible values to fill them are defined in this 
set of documents. Protocol fields will be defined in the message 
definitions. As an example, SSH MSG CHANNEL DATA is defined as 


follows. 
byte SSH MSG CHANNEL DATA 
uint32 recipient channel 


string data 


Throughout these documents, when the fields are referenced, they will 
appear within single quotes. When values to fill those fields are 
referenced, they will appear within double quotes. Using the above 
example, possible values for 'data' are "foo" and "bar". 


4. Connection Setup 


SSH works over any 8-bit clean, binary-transparent transport. The 
underlying transport SHOULD protect against transmission errors, as 
such errors cause the SSH connection to terminate. 


The client initiates the connection. 
4.1. Use over TCP/IP 


When used over TCP/IP, the server normally listens for connections on 
port 22. This port number has been registered with the IANA, and has 
been officially assigned for SSH. 


4.2. Protocol Version Exchange 


When the connection has been established, both sides MUST send an 
identification string. This identification string MUST be 


SSH-protoversion-softwareversion SP comments CR LF 


Since the protocol being defined in this set of documents is version 
2.0, the 'protoversion' MUST be "2.0". The 'comments' string is 
OPTIONAL. If the 'comments' string is included, a 'space' character 
(denoted above as SP, ASCII 32) MUST separate the 'softwareversion' 
and 'comments' strings. The identification MUST be terminated by a 
single Carriage Return (CR) and a single Line Feed (LF) character 
(ASCII 13 and 10, respectively).  Implementers who wish to maintain 
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compatibility with older, undocumented versions of this protocol may 
want to process the identification string without expecting the 
presence of the carriage return character for reasons described in 
Section 5 of this document. The null character MUST NOT be sent. 
The maximum length of the string is 255 characters, including the 
Carriage Return and Line Feed. 


The part of the identification string preceding the Carriage Return 
and Line Feed is used in the Diffie-Hellman key exchange (see Section 
8). 


The server MAY send other lines of data before sending the version 
String. Each line SHOULD be terminated by a Carriage Return and Line 
Feed. Such lines MUST NOT begin with "SSH-", and SHOULD be encoded 
in ISO-10646 UTF-8 [REC3629] (language is not specified). Clients 
MUST be able to process such lines. Such lines MAY be silently 
ignored, or MAY be displayed to the client user. If they are 
displayed, control character filtering, as discussed in [SSH-ARCH], 
SHOULD be used. The primary use of this feature is to allow TCP- 
wrappers to display an error message before disconnecting. 


Both the 'protoversion' and 'softwareversion' strings MUST consist of 
printable US-ASCII characters, with the exception of whitespace 
characters and the minus sign (-). The 'softwareversion' string is 
primarily used to trigger compatibility extensions and to indicate 
the capabilities of an implementation. The 'comments' string SHOULD 
contain additional information that might be useful in solving user 
problems. As such, an example of a valid identification string is 


SSH-2.0-billsSSH_3.6.3q3<CR><LF> 
This identification string does not contain the optional 'comments' 
string and is thus terminated by a CR and LF immediately after the 
'softwareversion' string. 
Key exchange will begin immediately after sending this identifier. 
All packets following the identification string SHALL use the binary 
packet protocol, which is described in Section 6. 


5. Compatibility With Old SSH Versions 


As stated earlier, the 'protoversion' specified for this protocol is 


"2.0". Earlier versions of this protocol have not been formally 
documented, but it is widely known that they use 'protoversion' of 
"1.x" (e.g., "1.5" or "1.3"). At the time of this writing, many 


implementations of SSH are utilizing protocol version 2.0, but it is 
known that there are still devices using the previous versions. 
During the transition period, it is important to be able to work in a 
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way that is compatible with the installed SSH clients and servers 
that use the older version of the protocol. Information in this 
Section is only relevant for implementations supporting compatibility 
with SSH versions 1.x. For those interested, the only known 
documentation of the 1.x protocol is contained in README files that 
are shipped along with the source code [ssh-1.2.30]. 


5.1. Old Client, New Server 


Server implementations MAY support a configurable compatibility flag 
that enables compatibility with old versions. When this flag is on, 
the server SHOULD identify its 'protoversion' as "1.99". Clients 
using protocol 2.0 MUST be able to identify this as identical to 
"2.0". In this mode, the server SHOULD NOT send the Carriage Return 
character (ASCII 13) after the identification string. 


In the compatibility mode, the server S 
data after sending its identification s 
identification string from the client. 


HOULD NOT send any further 
tring until it has received an 
The server can then determine 


whether the client is using an old protocol, and can revert to the 
old protocol if required. In the compatibility mode, the server MUST 
NOT send additional data before the identification string. 


When compatibility with old clients is not needed, the server MAY 
send its initial key exchange data immediately after the 
identification string. 


5.2. New Client, Old Server 


Since the new client MAY immediately send additional data after its 
identification string (before receiving the server's identification 
String), the old protocol may already be corrupt when the client 
learns that the server is old. When this happens, the client SHOULD 
close the connection to the server, and reconnect using the old 
protocol. 


5.3. Packet Size and Overhead 
Some readers will worry about the increase in packet size due to new 


headers, padding, and the Message Authentication Code (MAC). The 
minimum packet size is in the order of 28 bytes (depending on 


negotiated algorithms). The increase is negligible for large 
packets, but very significant for one-byte packets (telnet-type 
sessions). There are, however, several factors that make this a 


non-issue in almost all cases: 


o The minimum size of a TCP/IP header is 32 bytes. Thus, the 
increase is actually from 33 to 51 bytes (roughly). 
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o The minimum size of the data field of an Ethernet packet is 46 


bytes [RECO894]. Thus, the increase is no more than 5 bytes. 
When Ethernet headers are considered, the increase is less than 10 
percent. 


o The total fraction of telnet-type data in the Internet is 
negligible, even with increased packet sizes. 


The only environment where the packet size increase is likely to have 
a significant effect is PPP [REC1661] over slow modem lines (PPP 
compresses the TCP/IP headers, emphasizing the increase in packet 


size). However, with modern modems, the time needed to transfer is 
in the order of 2 milliseconds, which is a lot faster than people can 
type. 


There are also issues related to the maximum packet size. To 
minimize delays in screen updates, one does not want excessively 
large packets for interactive sessions. The maximum packet size is 
negotiated separately for each channel. 


6. Binary Packet Protocol 
Each packet is in the following format: 


uint32 packet length 

byte padding length 

byte[n1] payload; nl = packet length - padding length - 1 
byte[n2] random padding; n2 - padding length 

byte [m] mac (Message Authentication Code - MAC); m - mac length 


packet length 
The length of the packet in bytes, not including 'mac' or the 
'packet length' field itself. 


padding length 
Length of 'random padding' (bytes). 


payload 
The useful contents of the packet. If compression has been 
negotiated, this field is compressed. Initially, compression 
MUST be "none". 


random padding 
Arbitrary-length padding, such that the total length of 
(packet length || padding length || payload || random padding) 
is a multiple of the cipher block size or 8, whichever is 
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larger. There MUST be at least four bytes of padding. The 
padding SHOULD consist of random bytes. The maximum amount of 
padding is 255 bytes. 


mac 
Message Authentication Code. If message authentication has 
been negotiated, this field contains the MAC bytes. Initially, 
the MAC algorithm MUST be "none". 


Note that the length of the concatenation of 'packet length', 
'padding length', 'payload', and 'random padding' MUST be a multiple 
of the cipher block size or 8, whichever is larger. This constraint 
MUST be enforced, even when using stream ciphers. Note that the 
'packet length' field is also encrypted, and processing it requires 
Special care when sending or receiving packets. Also note that the 
insertion of variable amounts of 'random padding' may help thwart 
traffic analysis. 


The minimum size of a packet is 16 (or the cipher block size, 
whichever is larger) bytes (plus 'mac'). Implementations SHOULD 
decrypt the length after receiving the first 8 (or cipher block size, 
whichever is larger) bytes of a packet. 


6.1. Maximum Packet Length 


All implementations MUST be able to process packets with an 
uncompressed payload length of 32768 bytes or less and a total packet 
size of 35000 bytes or less (including 'packet length', 
"padding length', 'payload', 'random padding', and 'mac'). The 
maximum of 35000 bytes is an arbitrarily chosen value that is larger 
than the uncompressed length noted above.  Implementations SHOULD 
support longer packets, where they might be needed. For example, if 
an implementation wants to send a very large number of certificates, 
the larger packets MAY be sent if the identification string indicates 
that the other party is able to process them. However, 
implementations SHOULD check that the packet length is reasonable in 
order for the implementation to avoid denial of service and/or buffer 
overflow attacks. 


6.2. Compression 


If compression has been negotiated, the 'payload' field (and only it) 
will be compressed using the negotiated algorithm. The 

'packet length' field and 'mac' will be computed from the compressed 
payload. Encryption will be done after compression. 
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Compression MAY be stateful, depending on the method. Compression 
MUST be independent for each direction, and implementations MUST 
allow independent choosing of the algorithm for each direction. In 
practice however, it is RECOMMENDED that the compression method be 
the same in both directions. 


The following compression methods are currently defined: 


none REQUIRED no compression 
zlib OPTIONAL LIB (LZ77) compression 


N 


The "zlib" compression is described in [RFC1950] and in [RFC1951]. 
The compression context is initialized after each key exchange, and 
is passed from one packet to the next, with only a partial flush 
being performed at the end of each packet. A partial flush means 
that the current compressed block is ended and all data will be 
output. If the current block is not a stored block, one or more 
empty blocks are added after the current block to ensure that there 
are at least 8 bits, counting from the start of the end-of-block code 
of the current block to the end of the packet payload. 


Additional methods may be defined as specified in [SSH-ARCH] and 
[SSH-NUMBERS] . 


6.3. Encryption 


An encryption algorithm and a key will be negotiated during the key 
exchange. When encryption is in effect, the packet length, padding 
length, payload, and padding fields of each packet MUST be encrypted 
with the given algorithm. 

The encrypted data in all packets sent in one direction SHOULD be 
considered a single data stream. For example, initialization vectors 
SHOULD be passed from the end of one packet to the beginning of the 
next packet. All ciphers SHOULD use keys with an effective key 
length of 128 bits or more. 
The ciphers in each direction MUST run independently of each other. 
mplementations MUST allow the algorithm for each direction to be 
independently selected, if multiple algorithms are allowed by local 
policy. In practice however, it is RECOMMENDED that the same 
algorithm be used in both directions. 
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The following ciphers are currently defined: 


3des- 
blowf 
twofi 


twofi 
twofi 
twofi 


aes25 


aes19 
aes12 


serpent256-cbc OPTIONAL 


serpent192-cbc OPTIONAL 


cbc REQUIRED 
ish-cbc OPTIONAL 
sh256-cbo OPTIONAL 
sh-cbc OPTIONAL 
sh192-cbc OPTIONAL 


three-key 3DES in CBC mode 
Blowfish in CBC mode 
Twofish in CBC mode, 

with a 256-bit key 

alias for "twofish256-cbc" 
(this is being retained 
for historical reasons) 
Twofish with a 192-bit key 


sh128-cbc OPTIONAL Twofish with a 128-bit key 
6-cbc OPTIONAL AES in CBC mode, 

with a 256-bit key 
2-cbc OPTIONAL AES with a 192-bit key 
8-cbc RECOMMENDED AES with a 128-bit key 


Serpent in CBC mode, with 

a 256-bit key 

Serpent with a 192-bit key 
Serpent with a 128-bit key 

the ARCFOUR stream cipher 

with a 128-bit key 

IDEA in CBC mode 

CAST-128 in CBC mode 

no encryption; NOT RECOMMENDED 


e-key triple-DES (encrypt-decrypt- 


, where the first 8 bytes of the key are used for the first 


serpent128-cbc OPTIONAL 
arcfour OPTIONAL 
idea-cbc OPTIONAL 
cast128-cbc OPTIONAL 
none OPTIONAL 
The "3des-cbc" cipher is thre 
encrypt) 
encryption, the next 8 bytes 


for the decryption, and the following 8 


bytes for the final encryption. This requires 24 bytes of key data 


(of whic 
chaining 
vector). 


h 168 bits are actual 
MUST be used (i.e., 


ly used). To implement CBC mode, outer 
there is only one initialization 


This is a block cipher with 8-byte blocks. This algorithm 


is defined in [FIPS-46-3]. Note that since this algorithm only has 


an effec 


tive key length of 1 


I2 bits ([SCHNEIER]), it does not meet 


the specifications that SSH encryption algorithms should use keys of 


128 bits 


historical reasons; essential 


time of 


because it is the fundamental 


or more. However, t 


this writing support 


future time, it is expected t 
Strength, will become so prevalent and ubiquitous that the use of 


"3des-cbc" will be deprecated 


The "blowfish-cbc" cipher is 
[SCHNEIER]. This is a block 


Ylonen &  Lonvick Stan 


his algorithm is still REQUIRED for 

ly, all known implementations at the 
this algorithm, and it is commonly used 
interoperable algorithm. At some 

hat another algorithm, one with better 


by another STANDARDS ACTION. 


Blowfish in CBC mode, with 128-bit keys 
cipher with 8-byte blocks. 
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The "twofish-cbc" or "twofish256-cbc" cipher is Twofish in CBC mode, 
with 256-bit keys as described [TWOFISH]. This is a block cipher 
with 16-byte blocks. 


The "twofishl92-cbc" cipher is the same as above, but with a 192-bit 
key. 


The "twofishl28-cbc" cipher is the same as above, but with a 128-bit 
key. 


E 


T 


he "aes256-cbc" cipher is AES (Advanced Encryption Standard) 
FIPS-197], in CBC mode. This version uses a 256-bit key. 


3 


[The "aesl192-cbc" cipher is the same as above, but with a 192-bit key. 


E 


i 


he "aes128-cbc" cipher is the same as above, but with a 128-bit key. 


5 


= 


he "serpent256-cbc" cipher in CBC mode, with a 256-bit key as 
described in the Serpent AES submission. 


E 


= 


he "serpent192-cbc" cipher is the same as above, but with a 192-bit 
key. 


The "serpent128-cbc" cipher is the same as above, but with a 128-bit 
key. 


ü 


[The "arcfour" cipher is the Arcfour stream cipher with 128-bit keys. 
Ihe Arcfour cipher is believed to be compatible with the RC4 cipher 
SCHNEIER].  Arcfour (and RC4) has problems with weak keys, and 
should be used with caution. 


m 


The "idea-cbc" cipher is the IDEA cipher in CBC mode [SCHNEIER]. 


The "cast128-cbc" cipher is the CAST-128 cipher in CBC mode with a 
28-bit key [REC2144]. 


" 


[The "none" algorithm specifies that no encryption is to be done. 
Note that this method provides no confidentiality protection, and it 
is NOT RECOMMENDED. Some functionality (e.g., password 
authentication) may be disabled for security reasons if this cipher 
is chosen. 


Additional methods may be defined as specified in [SSH-ARCH] and in 
[SSH-NUMBERS] . 
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Data Integrity 


Data integrity is protected by including with each packet a MAC that 
is computed from a shared secret, packet sequence number, and the 
contents of the packet. 


The message authentication algorithm and key are negotiated during 
key exchange. Initially, no MAC will be in effect, and its length 
MUST be zero. After key exchange, the 'mac' for the selected MAC 
algorithm will be computed before encryption from the concatenation 
of packet data: 


mac = MAC(key, sequence number || unencrypted packet) 


where unencrypted packet is the entire packet without 'mac' (the 
length fields, 'payload' and 'random padding'), and sequence number 
is an implicit packet sequence number represented as uint32. The 
Sequence number is initialized to zero for the first packet, and is 
incremented after every packet (regardless of whether encryption or 
MAC is in use). It is never reset, even if keys/algorithms are 
renegotiated later. It wraps around to zero after every 2^32 
packets. The packet sequence number itself is not included in the 
packet sent over the wire. 


The MAC algorithms for each direction MUST run independently, and 
implementations MUST allow choosing the algorithm independently for 
both directions. In practice however, it is RECOMMENDED that the 
Same algorithm be used in both directions. 


The value of 'mac' resulting from the MAC algorithm MUST be 
transmitted without encryption as the last part of the packet. The 


number of 'mac' bytes depends on the algorithm chosen. 


The following MAC algorithms are currently defined: 


January 2006 


hmac-shal 


hmac-shal-96 RECOMME 


hmac-md5 


hmac-md5-96 


none 


The "hmac-*" algorithms 


nen &  Lonvick 


REQUIRED 


OPTIONAL 


OPTIONAL 


OPTIONAL 


DED 


HMAC-SHA1 
length = 
first 96 
length = 
HMAC-MD5 
length - 
first 96 
length - 


no MAC; NOT RECOMMENDED 


are described in 
use only the first n bits of the resulting value. 


Standards Track 


(digest leng 
20) 


th = key 


bits of HMAC-SHA1 (digest 


12, key lengt 
(digest lengt 
16) 

bits of HMAC- 
12, key lengt 


[REC2104]. T 


h = 
h = 


ne 


20) 
key 


(digest 
16) 


"*-n" MACs 
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SHA-1 is described in [FIPS-180-2] and MD5 is described in [RFC1321]. 


Additional methods may be defined, as specified in [SSH-ARCH] and in 
SSH-NUMBERS] . 


6.5. Key Exchange Methods 
The key exchange method specifies how one-time session keys are 


generated for encryption and for authentication, and how the server 
authentication is done. 


Two REQUIRED key exchange methods have been defined: 


diffie-hellman-groupl-shal REQUIRED 
diffie-hellman-groupl4-shal REQUIRED 


These methods are described in Section 8. 


Additional methods may be defined as specified in [SSH-NUMBERS]. The 
name "diffie-hellman-groupl-shal" is used for a key exchange method 
using an Oakley group, as defined in [REC2409]. SSH maintains its 


own group identifier space that is logically distinct from Oakley 
[REC2412] and IKE; however, for one additional group, the Working 
Group adopted the number assigned by [REC3526], using diffie- 
hellman-groupl4-shal for the name of the second defined group. 
Implementations should treat these names as opaque identifiers and 
Should not assume any relationship between the groups used by SSH and 
the groups defined for IKE. 


6.6. Public Key Algorithms 


This protocol has been designed to operate with almost any public key 
format, encoding, and algorithm (signature and/or encryption). 


There are several aspects that define a public key type: 


o Key format: how is the key encoded and how are certificates 
represented. The key blobs in this protocol MAY contain 
certificates in addition to keys. 


o Signature and/or encryption algorithms. Some key types may not 
support both signing and encryption. Key usage may also be 
restricted by policy statements (e.g., in certificates). In this 
case, different key types SHOULD be defined for the different 
policy alternatives. 


o Encoding of signatures and/or encrypted data. This includes but 
is not limited to padding, byte order, and data formats. 
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The following public key and/or certificate formats are currently 


defined: 

ssh-dss REQUIRED sign Raw DSS Key 

ssh-rsa RECOMMENDED sign Raw RSA Key 

pgp-sign-rsa OPTIONAL sign OpenPGP certificates (RSA key) 
pgp-sign-dss OPTIONAL sign OpenPGP certificates (DSS key) 


Additional key types may be defined, as specified in [SSH-ARCH] and 
in [SSH-NUMBERS]. 


The key type MUST always be explicitly known (from algorithm 
negotiation or some other source). It is not normally included in 


the key blob. 


Certificates and public keys are encoded as follows: 


string certificate or public key format identifier 
byte[n] key/certificate data 


The certificate part may be a zero length string, but a public key is 
required. This is the public key that will be used for 
authentication. The certificate sequence contained in the 
certificate blob can be used to provide authorization. 


Public key/certificate formats that do not explicitly specify a 
signature format identifier MUST use the public key/certificate 


format identifier as the signature identifier. 


Signatures are encoded as follows: 


string signature format identifier (as specified by the 
public key/certificate format) 
byte[n] signature blob in format specific encoding. 


The "ssh-dss" key format has the following specific encoding: 


string "ssh-dss" 
mpint p 
mpint q 
mpint g 
mpint y 


Here, the 'p', 'q', 'g', and 'y' parameters form the signature key 
blob. 
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Signing and verifying using this key format is done according to the 
Digital Signature Standard [FIPS-186-2] using the SHA-1 hash 
I[FIPS-180-4]. 


The resulting signature is encoded as follows: 


string "ssh-dss" 
string dss signature blob 


The value for 'dss signature blob' is encoded as a string containing 
r, followed by s (which are 160-bit integers, without lengths or 


padding, unsigned, and in network byte order). 


The "ssh-rsa" key format has the following specific encoding: 


string "ssh-rsa" 
mpint e 
mpint n 


Here the 'e' and 'n' parameters form the signature key blob. 


Signing and verifying using this key format is performed according to 
the RSASSA-PKCS1-v1 5 scheme in [RFC3447] using the SHA-1 hash. 


The resulting signature is encoded as follows: 


[0] 


tring "ssh-rsa" 
string rsa signature blob 


The value for 'rsa signature blob' is encoded as a string containing 
S (which is an integer, without lengths or padding, unsigned, and in 
network byte order). 


The "pgp-sign-rsa" method indicates the certificates, the public key, 
and the signature are in OpenPGP compatible binary format 
([REC2440]). This method indicates that the key is an RSA-key. 


The "pgp-sign-dss" is as above, but indicates that the key is a 
DSS-key. 


7. Key Exchange 


Key exchange (kex) begins by each side sending name-lists of 
supported algorithms. Each side has a preferred algorithm in each 
category, and it is assumed that most implementations, at any given 
time, will use the same preferred algorithm. Each side MAY guess 
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which algorithm the other side is using, and MAY send an initial key 
exchange packet according to the algorithm, if appropriate for the 
preferred method. 


The guess is considered wrong if: 


o the kex algorithm and/or the host key algorithm is guessed wrong 
(server and client have different preferred algorithm), or 


o if any of the other algorithms cannot be agreed upon (the 
procedure is defined below in Section 7.1). 


Otherwise, the guess is considered to be right, and the 
optimistically sent packet MUST be handled as the first key exchange 
packet. 


However, if the guess was wrong, and a packet was optimistically sent 
by one or both parties, such packets MUST be ignored (even if the 
error in the guess would not affect the contents of the initial 
packet(s)), and the appropriate side MUST send the correct initial 
packet. 


A key exchange method uses explicit server authentication if the key 
exchange messages include a signature or other proof of the server's 
authenticity. A key exchange method uses implicit server 
authentication if, in order to prove its authenticity, the server 
also has to prove that it knows the shared secret, K, by sending a 
message and a corresponding MAC that the client can verify. 


The key exchange method defined by this document uses explicit server 
authentication. However, key exchange methods with implicit server 
authentication MAY be used with this protocol. After a key exchange 
with implicit server authentication, the client MUST wait for a 
response to its service request message before sending any further 
data. 
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7.1. Algorithm Negotiation 


Key exchange begins by each side sending the following packet: 


byte SSH MSG KEXINIT 

byte[16] cookie (random bytes) 

name-list kex algorithms 

name-list server host key algorithms 

name-list encryption algorithms client to server 
name-list encryption algorithms server to client 
name-list mac algorithms client to server 
name-list mac algorithms server to client 
name-list compression algorithms client to server 
name-list compression algorithms server to client 
name-list languages client to server 

name-list languages server to client 

boolean first kex packet follows 

uint32 0 (reserved for future extension) 


Each of the algorithm name-lists MUST be a comma-separated list of 
algorithm names (see Algorithm Naming in [SSH-ARCH] and additional 
information in [SSH-NUMBERS]). Each supported (allowed) algorithm 
MUST be listed in order of preference, from most to least. 


The first algorithm in each name-list MUST be the preferred (guessed) 
algorithm. Each name-list MUST contain at least one algorithm name. 


cookie 
The 'cookie' MUST be a random value generated by the sender. 
Its purpose is to make it impossible for either side to fully 
determine the keys and the session identifier. 


kex algorithms 
Key exchange algorithms were defined above. The first 
algorithm MUST be the preferred (and guessed) algorithm. If 
both sides make the same guess, that algorithm MUST be used. 
Otherwise, the following algorithm MUST be used to choose a key 
exchange method: Iterate over client's kex algorithms, one at a 
time. Choose the first algorithm that satisfies the following 
conditions: 


+ the server also supports the algorithm, 


+ if the algorithm requires an encryption-capable host key, 
there is an encryption-capable algorithm on the server's 
server host key algorithms that is also supported by the 
client, and 
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+ if the algorithm requires a signature-capable host key, 
there is a signature-capable algorithm on the server's 
server host key algorithms that is also supported by the 
client. 


If no algorithm satisfying all these conditions can be found, the 
connection fails, and both sides MUST disconnect. 


server host key algorithms 
A name-list of the algorithms supported for the server host 
key. The server lists the algorithms for which it has host 
keys; the client lists the algorithms that it is willing to 
accept. There MAY be multiple host keys for a host, possibly 
with different algorithms. 


Some host keys may not support both signatures and encryption 
(this can be determined from the algorithm), and thus not all 
host keys are valid for all key exchange methods. 


Algorithm selection depends on whether the chosen key exchange 
algorithm requires a signature or an encryption-capable host 
key. It MUST be possible to determine this from the public key 
algorithm name. The first algorithm on the client's name-list 
that satisfies the requirements and is also supported by the 
Server MUST be chosen. If there is no such algorithm, both 
sides MUST disconnect. 


encryption algorithms 
A name-list of acceptable symmetric encryption algorithms (also 
known as ciphers) in order of preference. The chosen 
encryption algorithm to each direction MUST be the first 
algorithm on the client's name-list that is also on the 
Server's name-list. If there is no such algorithm, both sides 
MUST disconnect. 


Note that "none" must be explicitly listed if it is to be 
acceptable. The defined algorithm names are listed in Section 
643: 


mac algorithms 
A name-list of acceptable MAC algorithms in order of 
preference. The chosen MAC algorithm MUST be the first 
algorithm on the client's name-list that is also on the 
Server's name-list. If there is no such algorithm, both sides 
MUST disconnect. 


Note that "none" must be explicitly listed if it is to be 
acceptable. The MAC algorithm names are listed in Section 6.4. 
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compression algorithms 
A name-list of acceptable compression algorithms in order of 
preference. The chosen compression algorithm MUST be the first 
algorithm on the client's name-list that is also on the 
Server's name-list. If there is no such algorithm, both sides 
MUST disconnect. 


Note that "none" must be explicitly listed if it is to be 
acceptable. The compression algorithm names are listed in 
Section 6.2. 


languages 
This is a name-list of language tags in order of preference 
[REC3066]. Both parties MAY ignore this name-list. If there 
are no language preferences, this name-list SHOULD be empty as 
defined in Section 5 of [SSH-ARCH]. Language tags SHOULD NOT 
be present unless they are known to be needed by the sending 
party. 


first kex packet follows 
Indicates whether a guessed key exchange packet follows. If a 
guessed packet will be sent, this MUST be TRUE. If no guessed 
packet will be sent, this MUST be FALSE. 


After receiving the SSH MSG KEXINIT packet from the other side, 
each party will know whether their guess was right. If the 
other party's guess was wrong, and this field was TRUE, the 
next packet MUST be silently ignored, and both sides MUST then 
act as determined by the negotiated key exchange method. If 
the guess was right, key exchange MUST continue using the 
guessed packet. 


After the SSH MSG KEXINIT message exchange, the key exchange 
algorithm is run. It may involve several packet exchanges, as 
Specified by the key exchange method. 


Once a party has sent a SSH MSG KEXINIT message for key exchange or 
re-exchange, until it has sent a SSH MSG NEWKEYS message (Section 
7.3), it MUST NOT send any messages other than: 
o Transport layer generic messages (1 to 19) (but 

SSH MSG SERVICE REQUEST and SSH MSG SERVICE ACCEPT MUST NOT be 


sent); 


o Algorithm negotiation messages (20 to 29) (but further 
SSH MSG KEXINIT messages MUST NOT be sent); 


o Specific key exchange method messages (30 to 49). 
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The provisions of Section 11 apply to unrecognized messages. 


Note, however, that during a key re-exchange, after sending a 

SSH_MSG KEXINIT message, each party MUST be prepared to process an 
arbitrary number of messages that may be in-flight before receiving a 
SSH MSG KEXINIT message from the other party. 


.2. Output from Key Exchange 


The key exchange produces two values: a shared secret K, and an 
exchange hash H. Encryption and authentication keys are derived from 
these. The exchange hash H from the first key exchange is 
additionally used as the session identifier, which is a unique 
identifier for this connection. It is used by authentication methods 
as a part of the data that is signed as a proof of possession of a 
private key. Once computed, the session identifier is not changed, 
even if keys are later re-exchanged. 


Each key exchange method specifies a hash function that is used in 
the key exchange. The same hash algorithm MUST be used in key 
derivation. Here, we'll call it HASH. 


Encryption keys MUST be computed as HASH, of a known value and K, as 
follows: 


o Initial IV client to server: HASH(K || H "A" || session id) 
(Here K is encoded as mpint and "A" as byte and session id as raw 


data. "A" means the single character A, ASCII 65). 
o Initial IV server to client: HASH(K || H || "B" || session id) 
o Encryption key client to server: HASH(K || H || "C" || session id) 
o Encryption key server to client: HASH(K || H || "D" || session id) 
o Integrity key client to server: HASH(K || H || "E" || session id) 
o Integrity key server to client: HASH(K || H || "F" || session id) 


Key data MUST be taken from the beginning of the hash output. As 
many bytes as needed are taken from the beginning of the hash value. 
If the key length needed is longer than the output of the HASH, the 
key is extended by computing HASH of the concatenation of K and H and 
the entire key so far, and appending the resulting bytes (as many as 
HASH generates) to the key. This process is repeated until enough 
key material is available; the key is taken from the beginning of 
this value. In other words: 
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Kl = HASH(K || H || X || session id) (X is e.g., "A") 
K2 = HASH(K || H || K1) 
K3 = HASH(K || H || K1 || K2) 


key = K1 || K2 || K3 || 


This process will lose entropy if the amount of entropy in K is 
larger than the internal state size of HASH. 


7.3. Taking Keys Into Use 


Key exchange ends by each side sending an SSH MSG NEWKEYS message. 
This message is sent with the old keys and algorithms. All messages 
sent after this message MUST use the new keys and algorithms. 


When this message is received, the new keys and algorithms MUST be 
used for receiving. 


The purpose of this message is to ensure that a party is able to 
respond with an SSH MSG DISCONNECT message that the other party can 
understand if something goes wrong with the key exchange. 


byte SSH MSG NEWKEYS 
8. Diffie-Hellman Key Exchange 


The Diffie-Hellman (DH) key exchange provides a shared secret that 
cannot be determined by either party alone. The key exchange is 
combined with a signature with the host key to provide host 
authentication. This key exchange method provides explicit server 
authentication as defined in Section 7. 


The following steps are used to exchange a key. In this, C is the 
client; S is the server; p is a large safe prime; g is a generator 
for a subgroup of GF(p); q is the order of the subgroup; V S is S's 
identification string; V C is C's identification string; K S is S's 
public host key; I C is C's SSH MSG KEXINIT message and I S is S's 
SSH MSG KEXINIT message that have been exchanged before this part 
begins. 


1. C generates a random number x (1 < x < q) and computes 
e = g^x mod p. C sends e to S. 
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2. S generates a random number y (0 < y < q) and computes 
f = g^y mod p. S receives e. It computes K = e^y mod p, 
H-hash(VC || VS I| ICII IS /!| KS |I e II £ II K) 
(these elements are encoded according to their types; see below), 
and signature s on H with its private host key. S sends 
(KS || £ || s) to C. The signing operation may involve a 
second hashing operation. 


3. C verifies that K S really is the host key for S (e.g., using 
certificates or a local database). C is also allowed to accept 
the key without verification; however, doing so will render the 
protocol insecure against active attacks (but may be desirable for 


practical reasons in the short term in many environments). C then 
computes K = f^x mod p, H = hash(VC || VS I| IC || IS || KS 
|| ell £ || K), and verifies the signature s on H. 


Values of 'e' or 'f' that are not in the range [1, p-1] MUST NOT be 
sent or accepted by either side. If this condition is violated, the 
key exchange fails. 


This is implemented with the following messages. The hash algorithm 
for computing the exchange hash is defined by the method name, and is 
called HASH. The public key algorithm for signing is negotiated with 
the SSH MSG KEXINIT messages. 


First, the client sends the following: 


byte SSH MSG KEXDH INIT 
mpint e 


The server then responds with the following: 


byte SSH MSG KEXDH REPLY 
string server public host key and certificates (K S) 
mpint f 
string signature of H 
Ylonen & Lonvick Standards Track [Page 22] 


http://tools.ietf.org/html/rfc4253 22/32 


RFC 4253 - The Secure Shell (SSH) Transport Layer Protocol 06/05/2014 


REC 4253 SSH Transport Layer Protocol January 2006 


The hash H is computed as the HASH hash of the concatenation of the 
following: 
string V C, the client's identification string (CR and LF 
excluded) 
string V S, the server's identification string (CR and LF 
excluded) 
string I C, the payload of the client's SSH MSG KEXINIT 
string I S, the payload of the server's SSH MSG KEXINIT 
string K S, the host key 
mpint e, exchange value sent by the client 
mpint f, exchange value sent by the server 
mpint K, the shared secret 


This value is called the exchange hash, and it is used to 
authenticate the key exchange. The exchange hash SHOULD be kept 
secret. 


The signature algorithm MUST be applied over H, not the original 
data. Most signature algorithms include hashing and additional 
padding (e.g., "ssh-dss" specifies SHA-1 hashing). In that case, the 
data is first hashed with HASH to compute H, and H is then hashed 
with SHA-1 as part of the signing operation. 


8.1. diffie-hellman-groupl-shal 


The "diffie-hellman-groupl-shal" method specifies the Diffie-Hellman 
key exchange with SHA-1 as HASH, and Oakley Group 2 [REC2409] (1024- 
bit MODP Group). This method MUST be supported for interoperability 
as all of the known implementations currently support it. Note that 
this method is named using the phrase "groupl", even though it 
specifies the use of Oakley Group 2. 


8.2. diffie-hellman-groupl4-shal 


The "diffie-hellman-groupl4-shal" method specifies a Diffie-Hellman 
key exchange with SHA-1 as HASH and Oakley Group 14 [RFC3526] (2048- 
bit MODP Group), and it MUST also be supported. 


9. Key Re-Exchange 


Key re-exchange is started by sending an SSH MSG KEXINIT packet when 
not already doing a key exchange (as described in Section 7.1). When 
this message is received, a party MUST respond with its own 

SSH MSG KEXINIT message, except when the received SSH MSG KEXINIT 
already was a reply. Either party MAY initiate the re-exchange, but 
roles MUST NOT be changed (i.e., the server remains the server, and 
the client remains the client). 
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Key re-exchange is performed using whatever encryption was in effect 
when the exchange was started. Encryption, compression, and MAC 
methods are not changed before a new SSH MSG NEWKEYS is sent after 
the key exchange (as in the initial key exchange).  Re-exchange is 
processed identically to the initial key exchange, except for the 
Session identifier that will remain unchanged. It is permissible to 
change some or all of the algorithms during the re-exchange. Host 
keys can also change. All keys and initialization vectors are 
recomputed after the exchange. Compression and encryption contexts 
are reset. 


It is RECOMMENDED that the keys be changed after each gigabyte of 
transmitted data or after each hour of connection time, whichever 
comes sooner. However, since the re-exchange is a public key 
operation, it requires a fair amount of processing power and should 
not be performed too often. 


More application data may be sent after the SSH MSG NEWKEYS packet 
has been sent; key exchange does not affect the protocols that lie 
above the SSH transport layer. 


10. Service Request 
After the key exchange, the client requests a service. The service 


is identified by a name. The format of names and procedures for 
defining new names are defined in [SSH-ARCH] and [SSH-N ERS]. 


Currently, the following names have been reserved: 


ssh-userauth 
ssh-connection 


Similar local naming policy is applied to the service names, as is 
applied to the algorithm names. A local service should use the 


PRIVATE USE syntax of "servicename@domain". 


byte SSH MSG SERVICE REQUEST 
string Service name 


If the server rejects the service request, it SHOULD send an 
appropriate SSH MSG DISCONNECT message and MUST disconnect. 


When the service starts, it may have access to the session identifier 
generated during the key exchange. 
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If the server supports the service (and permits the client to use 
it), it MUST respond with the following: 


byte SSH MSG SERVICE ACCEPT 
string service name 


Message numbers used by services should be in the area reserved for 
them (see [SSH-ARCH] and [SSH-NUMBERS]). The transport level will 
continue to process its own messages. 


Note that after a key exchange with implicit server authentication, 
the client MUST wait for a response to its service request message 
before sending any further data. 


Additional Messages 
Either party may send any of the following messages at any time. 
1. Disconnection Message 


byte SSH MSG DISCONNECT 

uint32 reason code 

string description in ISO-10646 UTF-8 encoding [REC3629] 
string language tag [REC3066] 


This message causes immediate termination of the connection. All 
implementations MUST be able to process this message; they SHOULD be 
able to send this message. 


The sender MUST NOT send or receive any data after this message, and 
the recipient MUST NOT accept any data after receiving this message. 
The Disconnection Message 'description' string gives a more specific 
explanation in a human-readable form. The Disconnection Message 
'reason code' gives the reason in a more machine-readable format 
(suitable for localization), and can have the values as displayed in 
the table below. Note that the decimal representation is displayed 
in this table for readability, but the values are actually uint32 
values. 
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Symbolic name reason code 


SSH DISCONNECT HOST NOT ALLOWED TO CONNECT 
SSH DISCONNECT PROTOCOL ERROR 


SSH DISCONNECT KEY EXCHANGE FAILED 
SSH DISCONNECT RESERVED 

SSH DISCONNECT MAC ERROR 
SSH DISCONNECT COMPRESSION ERROR 


SSH DISCONNECT SERVICE NOT AVAILABLE 


SSH DISCONNECT PROTOCOL VERSION NOT SUPPORTED 


SSH DISCONNECT HOST KEY NOT VERIFIABLE 
SSH DISCONNECT CONNECTION LOST 


SSH DISCONNECT BY APPLICATION 

SSH DISCONNECT TOO MANY CONNECTIONS 

SSH DISCONNECT AUTH CANCELLED BY USER 

SSH DISCONNECT NO MORE AUTH METHODS AVAILABLE 


SSH DISCONNECT ILLEGAL USER NAME 


HÉBpB|bpmBDpPnmIiI 
OPWNHF CO g0 -1o0 0)! 0€ N PI| 


If the 'description' string is displayed, the control character 
filtering discussed in [SSH-ARCH] should be used to avoid attacks by 
sending terminal control characters. 


Requests for assignments of new Disconnection Message 'reason code' 
values (and associated 'description' text) in the range of 0x00000010 
to OxFDFFFFFF MUST be done through the IETF CONSENSUS method, as 
described in [REC2434]. The Disconnection Message 'reason code' 
values in the range of OxFE000000 through OxFFFFFFFF are reserved for 
PRIVATE USE. As noted, the actual instructions to the IANA are in 
[SSH-NUMBERS] . 


11.2. Ignored Data Message 


byte SSH MSG IGNORE 
string data 


All implementations MUST understand (and ignore) this message at any 
time (after receiving the identification string). No implementation 
is required to send them. This message can be used as an additional 
protection measure against advanced traffic analysis techniques. 


11.3. Debug Message 
byte SSH MSG DEBUG 
boolean always display 


string message in ISO-10646 UTF-8 encoding [REC3629] 
string language tag [REC3066] 
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All implementations MUST understand this message, but they are 
allowed to ignore it. This message is used to transmit information 
that may help debugging. If 'always display' is TRUE, the message 
SHOULD be displayed. Otherwise, it SHOULD NOT be displayed unless 
debugging information has been explicitly requested by the user. 


The 'message' doesn't need to contain a newline. It is, however, 
allowed to consist of multiple lines separated by CRLF (Carriage 
Return - Line Feed) pairs. 


If the 'message' string is displayed, the terminal control character 
filtering discussed in [SSH-ARCH] should be used to avoid attacks by 
sending terminal control characters. 


4. Reserved Messages 


An implementation MUST respond to all unrecognized messages with an 
SSH MSG UNIMPLEMENTED message in the order in which the messages were 
received. Such messages MUST be otherwise ignored. Later protocol 
versions may define other meanings for these message types. 


byte SSH MSG UNIMPLEMENTED 
uint32 packet sequence number of rejected message 


Summary of Message Numbers 


The following is a summary of messages and their associated message 
number. 


SSH MSG DISCONNECT 
SSH MSG IGNORE 

SSH MSG UNIMPLEMENTED 
SSH MSG DEBUG 
SSH MSG SERVICE REQUEST 
SSH MSG SERVICE ACCEPT 
SSH MSG KEXINIT 

SSH MSG NEWKEYS 


No ND OY O1 iS CO ND S 


jp: C2 


Note that numbers 30-49 are used for kex packets. Different kex 
methods may reuse message numbers in this range. 


IANA Considerations 
This document is part of a set. The IANA considerations for the SSH 


protocol as defined in [SSH-ARCH], [SSH-USERAUTH], [SSH-CONNECT], and 
this document, are detailed in [SSH-NUMBERS]. 
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14. Security Considerations 


This protocol provides a secure encrypted channel over an insecure 
network. It performs server host authentication, key exchange, 
encryption, and integrity protection. It also derives a unique 
Session ID that may be used by higher-level protocols. 


Full security considerations for this protocol are provided in 
[SSH-ARCH]. 
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